Systems and methods to control access to components of virtual objects

ABSTRACT

A computing system and method to implement a three-dimensional virtual reality world having user created virtual objects. A platonic object identifies a list of objects as different versions of the platonic object. Each respective object has: a blueprint identifying resource objects that are used to construct the respective object in the virtual reality world; and a provenance node identifying the platonic object of the respective object, a creator of the respective object, and a set of access control parameters of the respective object. A server computer hosting the virtual reality world control access to instances of the platonic object according to access control parameters stored in the tree of provenance nodes for the objects connected via the blueprints and the platonic object.

RELATED APPLICATION

The present application is a continuation application of U.S. patentapplication Ser. No. 17/214,252, filed Mar. 26, 2021, issued as U.S.Pat. No. 11,727,123 on Aug. 15, 2023, which is a continuationapplication of U.S. patent application Ser. No. 15/594,358, filed May12, 2017, issued as U.S. Pat. No. 10,963,931 on Mar. 30, 2021, andentitled “Systems and Methods to Control Access to Components of VirtualObjects,” the entire disclosure of which application is herebyincorporated herein by reference.

FIELD OF THE TECHNOLOGY

At least some technologies disclosed herein relate to informationsecurity and access control in general and more specifically, but notlimited to, access to virtual objects in a three-dimensional virtualworld.

BACKGROUND

Computer technologies have developed for the presentation ofthree-dimensional virtual worlds to users of computing devices.

For example, a virtual world can be hosted on a set of server computers(e.g., secondlife.com). Client programs or viewers can be installed onuser computers for connections to the server computers and for userparticipation in the virtual world. Users of a virtual world can bepresented as the residents of the virtual world in the form of avatars.The resident avatars can travel in the three-dimensional virtual world,explore the three-dimensional virtual world, meet other resident avatarsfor virtual social activities, and communicate with each other viavoice, instant messaging, text chart, local chat, and/or group chat. Theavatars may build, create, shop and trade virtual objects and serviceswith each other in the three-dimensional virtual world.

Avatars of a virtual world may take various forms, such as human,animal, vegetable, etc. In a virtual world, users may customize variousaspects of their avatars and may choose to resemble the users themselvesin appearance as they are in the real world. A user may have multipleavatars, but use only one avatar at a time for participation in thevirtual world.

In a virtual world, a user of a client program or viewer of the virtualworld can use conventional input devices to control the activities ofthe avatar that represents the user in the virtual world, such askeyboards and pointer control device (e.g., mouse, touch pad, trackball, joystick, and touch screen). The view of the virtual world ascurrently being seen by the avatar at its current position andorientation can be presented on a display device, such as a computermonitor, a display of a notebook computer, and a touch screen of amobile device.

A virtual world may allow the users to create virtual objects in thevirtual worlds and obtain virtual objects created by others to modifyand/or assemble them to create new virtual objects. A creator of avirtual object may want a level of control on the usage, distribution,and/or replication of the virtual object by other users, such as the useof the virtual object and its components in the creation of new virtualobjects. The creator may want to upgrade/update of virtual object whenthe updates/upgrades of the component objects used in the virtual objectbecomes available.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments are illustrated by way of example and not limitation inthe figures of the accompanying drawings in which like referencesindicate similar elements.

FIG. 1 shows a computer system in which techniques of the presentdisclosure can be used.

FIG. 2 shows a data structure of a virtual object to facilitate accesscontrol according to one embodiment.

FIG. 3 illustrates a platonic object to facilitate access controlaccording to one embodiment.

FIG. 4 illustrates a provenance node of a virtual object to facilitateaccess control according to one embodiment.

FIG. 5 illustrates a data structure to implement access control for avirtual object having multiple versions according to one embodiment.

FIG. 6 shows a method to implement access control for virtual objects ina virtual reality world according to one embodiment.

FIG. 7 shows a data processing system on which the methods of thepresent disclosure can be implemented.

DETAILED DESCRIPTION

The following description and drawings are illustrative and are not tobe construed as limiting. Numerous specific details are described toprovide a thorough understanding. However, in certain instances, wellknown or conventional details are not described in order to avoidobscuring the description. References to one or an embodiment in thepresent disclosure are not necessarily references to the sameembodiment; and, such references mean at least one.

A virtual world may allow its users to create virtual objects to enrichthe virtual world. For example, a first user may create a virtual wheel;a second user may use instances of the virtual wheel in constructing avirtual vehicle; and a third user may modify the virtual vehicle tocreate an improved vehicle. In such a scenario, the virtual wheelcreated by the first user may be replicated as instances by the seconduser, used as components of the virtual vehicle created by the seconduser, and reused, as components being integrated in the virtual vehicle,in the creation of the improved vehicle made by the third user. Thevirtual wheels, the virtual vehicle, and the improved vehicle may haveinstances used by other users with or without modification. The virtualobjects are presented as part of the virtual world. Thus, the usercreated objects enriches the virtual world over time. Further, when thefirst user improves the virtual wheel to provide an updated/upgradedvirtual wheel, it is desirable to update/upgrade at least some of theinstances of the virtual wheel, as well as other virtual objects thatuse the virtual wheel as components, such as the virtual vehicle, theimproved virtual vehicle, and their instances.

In the virtual world, perfect instances of a virtual object can beeasily “manufactured” via data replication and/or reference withoutusers making significant efforts. However, the creation of uniquevirtual objects requires significant contributions from the creators ofthe virtual objects. Thus, the creators may want to control thedistribution and use of their creations.

It is a challenge to efficiently and effectively track the permissionsof virtual objects, as the virtual objects are replicated with orwithout modification and/or integrated into new creations.

The present disclosure provides data structure techniques to addresssuch a challenge.

In one aspect, a blueprint of virtual object is used to identify theconstruction of the virtual object from its component resources. Aprovenance node of the virtual object is used to track the creator ofthe virtual object, and the parameters for access control related to theusage of the virtual object and/or its component resources. A provenancetree, formed by linking the provenance node of the virtual object to therespective provenance nodes of the component resources, specifies theaccess control parameters of the entire component tree of the virtualobject. Access controls can be prescribed by creators of virtual objectsand applied efficiently, even when some of the virtual objects areextracted from other virtual objects as component resources and builtinto new virtual objects.

In another aspect, a platonic object is used to provide aversion-neutral representation of different versions of virtual object.An instance of a virtual object acquired by a user is represented by areference to the platonic object, which allows the efficient tracking ofupgradable relations among multiple versions of virtual object.

A typical avatar in a three-dimensional virtual world has a position andorientation. A user device provides inputs to control the position andorientation of the avatar in the virtual world to simulate theexperience of traveling in the virtual world by presenting the virtualworld from the point of view of the position and orientation of theavatar. The virtual reality system (e.g., a server system and/or theclient program/viewer) renders a view of the virtual world based onposition and orientation of the avatar and presents the view of thevirtual world on the user device. The view of the virtual world includesother avatars in the field of view of the avatar, and other virtualobjects, such as virtual building, parks, theaters, streets, etc.

Within the view of the virtual world, the virtual reality system mayidentify a set of objects or avatars that may be of particular interestto the avatar. For examples, when an avatar speaks to a nearby listeningavatar, the listening avatar may become a point of interest for the gazeof the speaking avatar. For examples, when an avatar listens to a nearbyspeaking avatar, the speaking avatar may become a point of interest forthe gaze of the listening avatar. For examples, when an avatar speaks toa group of avatars, the avatars in the group may become potential pointsof interest for the gaze of the speaking avatar. A computer systemhosting the virtual world renders a view of the virtual world from thepoint of the gaze of the avatar and the present the view to the user ofthe avatar, as if the user of the avatar is viewing the virtual worldaccording to the gaze of the avatar.

FIG. 1 shows a computer system in which techniques of the presentdisclosure can be used.

In FIG. 1 , a server system (103) has a data storage (105) storing athree dimensional world model (131) and avatar models (135). The virtualworld represented by the model (131) may or may not resemble a part ofthe real world on the Earth. Client devices (107, . . . , 109) can beused to access the virtual world via the server system (103). Forexample, the server system (103) may generate a view of the virtualworld and provide the view to a client device (109) for display. Forexample, the server system (103) may extract a portion of the worldmodel (131) and the avatar model (135) relevant for the display of theview for the client device (109); and the client device (109) constructsa view of the portion of the virtual world from the data extracted andprovided by the server system (103).

In FIG. 1 , a user of the server system (103) has a user account (137)stored in the data storage (105). The user account (137) hostsinformation such as the identification of an avatar (141) of the user inthe virtual world, the location (143) and orientation (145) of theavatar (141) in the virtual world, preferences (147) of the user, suchas the personalization parameters of the avatar (141).

After a user of a client device (109) is authenticated for theauthorization to access the virtual world via the user account (137),the input devices (125) of the client device (109) provide user inputsto control the location (143) and orientation (145) of the avatar (141)of the user; and the server system (103) provides a data stream to theclient device (109) according to the location (143) and the orientation(145) of the avatar (141) such that the client device (109) presents, onthe output device (127), the view of the virtual world that is perceivedto be seen in the eyes of the avatar (141). The view of the virtualworld simulates the experience of a user in the virtual world at thelocation (143) and orientation (145) of the avatar (141); and thedisplay of the virtual world on the client device (109) corresponds tothe presentation of a video stream captured by a virtual camera at alocation (143) and orientation (145) of the avatar (141). Since the viewis in the eyes of the avatar (141), the view generally does not includethe avatar (141) itself and more specifically the eyes of the avatar(141). However, the avatar (141) itself and the eyes of the avatar (141)can be in the views of other avatars that are in the vicinity of theavatar (141).

Examples of the input devices (125) include a text input device (117)(such as a keyboard, a virtual keyboard implemented on a touch screen,text input implemented via speech recognition), a pointer control device(e.g., arrow keys of a keyboard, a mouse, a track ball, a touch pad, atouch screen, a joystick), a motion tracking device (e.g., motionsensors attached to a head-mount display, data glove, mobile phones,personal media player, mobile computing device, game controller), adigital camera (113), a microphone (111), etc.

Examples of the output devices (127) include a display (121) (e.g., acomputer monitor, a touch screen, a head-mount display, a virtualreality headset) and a speaker (123) (or earphone, headphone.

In some instances, a client device (109) has an eye-tracking capability(e.g., via a head-mount camera (113) that capture video images of theeyes of the user, a front facing camera (113) of a smart phone, a tabletcomputer, a mobile device), which makes it possible to control the eyemovements of an avatar (141) and/or the field of view of the avatar(141) independent of the movement of the location (143) and orientation(141) of the avatar (141) as a whole.

In some instances, when the client device (109) does not have aneye-tracking capability, the system is configured to present eyemovements based on predictions, eye movement models, preferences (147),and other inputs from other devices (e.g., 117, 119). For example,predetermined patterns of eye movements are animated based onpredetermined models. Thus, the experiences of the user of the avatar(141) can be improved, as well as the experiences of other usersinteracting with the avatar (141) of the user in the virtual world.

The system of FIG. 1 can also be used for the presentation of augmentedreality, where virtual representations of users in the form of avatarsare projected into a view of a real world. The avatars may have the formof a human and/or be generated based on images of the users of theavatars so that the avatars resemble the users in real world.

FIG. 1 illustrates the use of a centralized server system (103) to hostthe virtual world represented by the world model (131). In otherimplementations, the virtual world may be hosted on a distributedcomputer network.

In FIG. 1 , the user account (137) may include a number of virtualobjects (129), such as virtual vehicles, virtual televisions, virtualtelephones, etc. Some of the virtual objects (129) may be created byother users of the virtual world and acquired by the user of the account(137); and some of the virtual objects (129) may be created by the userof the account (137) using tools and/or building blocks offered by theserver system (103) and/or virtual objects created and offered by usersof other accounts.

In FIG. 1 , the data storage (105) stores the permission data (149) thatcontrols the access to virtual objects (e.g., 129), instances of whichmay be acquired by some users of the server system (103), and/ormodified or used to create new virtual objects which may be furthermodified or used in the creation of other virtual objects.

In one implementation, a typical virtual object (129), like an avatar(141), has a position and orientation, a shape, a size, and a visualrepresentation in the virtual world. When the virtual object (129) iswithin the field of view of the avatar (141), the virtual object (129)is presented as part of the virtual world at the position of the virtualobject (129) in the virtual world. Thus, the avatar (141) may approachand interact with the virtual object (129). When the virtual object(129) is acquired by the avatar (141), a copy or instance of the virtualobject (129) is created at a location selected by the avatar (141).

Some of the virtual objects (129) may be decorative items in the virtualworld (e.g., virtual clothing). Some of the virtual objects (129) mayhave pre-programmed functions that allow an avatar (141) to interactwith the virtual objects (129). For example, a virtual vehicle may havea control that allows an avatar to drive it around in the virtualreality world.

FIG. 2 shows a data structure of a virtual object to facilitate accesscontrol according to one embodiment. For example, the data structure ofFIG. 2 can be used to specify the structure and access control of one ofthe objects (129) created by the user of the account (137) illustratedin FIG. 1 .

In FIG. 2 , the object (151) includes a blueprint that specifies theconstruction of the object (151) from a set of objects (153, 155, . . ., 157) that are used as resources or components. The resource objects(153, 155, . . . , 157) can be placed at predetermined positions inspace relative to each other according to the design of the blueprint.The blueprint may specify the ways the resource objects (153, 155, . . ., 157) are connected to each other and the configurations of theresource objects (153, 155, . . . , 157) within the object (151).

A resource object (e.g., 157) itself may be constructed from a pluralityof objects (e.g., 161); and the blueprint of the object (151) mayspecify the use of some of the objects (e.g., 161) extracted from theresource object (e.g., 157) in the construction of the object (151).Some of the objects (e.g., 161) of the resource object (e.g., 157) maybe not used in the object (151); and such unused objects may or may notbe allowed to be used outside the object (151).

As an example, the resource object (157) may be used as a resourcebundle that allows a creator of the object (151) to selectively use someof the objects (e.g., 161) in the resource bundle to create the object(151). Unused portions of the resource bundle may or may not be allowedto be used in the creation of another object separate from the object(151).

The resource object (157) may have a blueprint identifying a particularways to connect its resource objects (e.g., 161); and in constructingthe object (151), the creator of the object (151) may use some of theconnections of a subset of the objects (161), discard or modify otherconnections, and/or discard or replace other objects. Thus, theblueprint of the resource object (157) may be partially used in theblueprint of the object (151).

In FIG. 2 , the configuration parameters (159) of the object (151)specify the way the object (151) is configured and/or constructed fromits resource objects (153, 155, . . . , 157). The configurationparameters (159) may include user-customizable parameters andnon-customizable parameters. User-customizable parameters allow anend-user of the object (151) to personalize an instance of the object(151) without creating a new object. Non-customizable parameters definethe character and property of the object (151). Adjustments to any ofthe non-customizable parameters lead to the creation of a new object;the user who makes the adjustments becomes the creator of the newobject; and the object (151) is a resource of the new object.

In FIG. 2 , the object (151) has an object ID (158) that identifies theobject (151). Instances of the object (151) can be created with areference to the object ID (158) so that the blueprint of the object(151) can be used for the rendering of the instances (e.g., based on thelocation and orientation of the instance in the virtual world, and theuser-customizable parameters specified for the respective instances).

In FIG. 2 , the object (151) includes a provenance node (171) thatspecifies the access control parameters. The creator of the object (151)can use the control parameters to specify the conditions for the use theobject (151), whether the object (171) is modifiable, and whether theresource objects (153, 155, . . . , 157) can be separately extracted forthe creation of different new objects. FIG. 4 provides an example of theprovenance node (171).

FIG. 3 illustrates a platonic object to facilitate access controlaccording to one embodiment. The platonic object (163) of FIG. 3 is aversion-neutral representation of different object versions tofacilitate the control of access to updates and upgrades.

In FIG. 3 , the platonic object (163) includes a name (164) of theobject (163), an ID (165) of the platonic object (163) for efficient andunique reference, and a list of object IDs (e.g., 167, 168, . . . , 169)of multiple versions of the platonic object (163). When a new version iscreated, the object ID of the new version is added to the list. Theobjects identified by the object IDs (e.g., 167, 168, . . . , 169) havethe specific blueprints for the construction and implementation of theversions of the platonic object (163).

For example, a virtual world may allow the creator of an object (151) tomake incremental improvements of the object (151) and thus createdifferent versions. The objects (e.g., 151) of different versions arerepresented by the same platonic object (163). Instances of the object(151) corresponding to a particular version can be generated as aninstance of the platonic object (163) having the corresponding version,such that access to the instance leads easily to the different versionsof the platonic object (163).

For example, when a creator initially constructs the object (151) from aset of resource objects (153, 155, . . . , 157), a first version of theobject (151) is created with the object ID (158); and a platonic object(163) is created to provide a version-neutral representation of theobject (151) and its potential successors/updates/upgrades. The platonicobject (163) includes it name (164), a platonic object ID (165), and anidentification of the object ID (158) in the field for the object ID ofversion 1 (167). When the creator improves the object (151) to create asuccessor object corresponding to the next version of the platonicobject (163), the platonic object (163) is updated to include the objectID of the successor object in the field of object ID of version 2 (168).Thus, the platonic object (163) provides efficient access to both theobject (151) and its successor.

In some instances, the object IDs (167, 168, . . . , 169) of differentversions are stored as an ordered array or a linked list in the platonicobject (163) to provide access to a set of objects according to theirrevision history of evolving from one version to another. In someinstances, the platonic object (163) also includes information aboutcompatibility among the versions to facilitate automated update/upgradeto compatible version. The data storage (105) of the server system (103)stores actual objects of different versions (e.g., 151) that contain theblueprints and access control parameters of the actual objects, suchthat instances of the actual objects can be accessed via the object IDs(167, 168, . . . , 169) provided in the platonic object (163) (e.g., fortesting and/or updating/upgrading).

Different instances of different versions of the platonic object (163)can be acquired by users of different accounts (e.g., 137) and bepresented in the virtual world according to their respective blueprintsand the locations of the instances. When a user obtains an instance of aversion of the platonic object (163), the instance is rendered accordingto the blueprint of the corresponding object (e.g., 151) identified bythe object ID specified for the corresponding version.

In some instances, the creator may offer a free update or upgrade of aninstance of the platonic object (163) having a version corresponding tothe object (151) to a newer version. During the rendering or processingof the instance of the platonic object (163), the server system (103)may automatically update the instance, according to the reference to thenew version identified in the list of object IDs stored in the platonicobject (163), with or without explicit input from the user. For example,the user may have a preference (147) stored in the user account (137) toaccept automatic updates/upgrades. In some instances, the server system(103) may prompt the user to indicate whether or not to update/upgrade,when, e.g., the update/upgrade has a potential incompatibility orrequires a cost. In some instances, the server system (103) may allowthe user to test the updated/upgraded object before finalizing theupdate/upgrade of the instance acquired by the user.

When an instance of the platonic object (163) is used as a resourceobject (e.g., 157) in the blueprint of another object (e.g., 151), theserver system (103) may generate an automated notification to thecreator of the object (151) about availability of the update/upgrade,such that the creator may test the update/upgrade for the use in theobject (151) and determine whether to use the updated/upgraded object(157) for the object (151), and/or to generate an update/upgradedversion of the object (151) in view of the available new version of theplatonic object (163).

Thus, the use of the platonic object (163) simplifies the processing ofobject updates/upgrades in a complex environment where multiple versionsof an object can coexist in the virtual world stand-alone and beingintegrated as components in the construction of other objects in thevirtual world.

FIG. 4 illustrates a provenance node of a virtual object to facilitateaccess control according to one embodiment. For example, the structureof the provenance node (171) of FIG. 4 can be used to implement theprovenance node (171) of the object (151) illustrated in FIG. 2 .

In FIG. 4 , the provenance node (171) has an ID (173) that uniquelyidentifies the provenance node (171) among provenance nodes of variousobjects (e.g., 151). In some instances, a reference to the provenancenode ID (173) by an object (151 or 163) or an instance of the object(151 or 163) is used to connect the object (151 or 163) to the accesscontrol parameters specified in the provenance node (171).

In FIG. 4 , the provenance node (171) has a creator ID (174) thatidentifies the identity of the object creator (e.g., the user whospecifies the blueprint of the object (151) to which the provenance node(171) is attached). The object creator has the privilege to adjust theparameters specified in the provenance node (171), such as a license ID(176), a price (177) of the object (171) for which the provenance node(171) is specified, a modifiability flag (178) of the object (171), anextractability flag (179) of the object (171), etc. Users other than thecreator do not have the privilege to adjust the provenance node (171).

In FIG. 4 , the provenance node (171) includes a platonic object ID(165) that identifies the platonic object (163) of the object (151) forwhich the provenance node (171) is specified. Thus, given an object(151) that is a specific version of the platonic object (163), theserver system (103) can extract the platonic object ID (165) from itsprovenance node (171) and check the version history of the platonicobject (163) identified by the platonic object ID (165).

For example, when the user of the account (137) acquires the object(151), the server system (103) may use the provenance node (171) of theobject (151) to identify the platonic object (163) through the platonicobject ID (165) specified in the provenance node (171) and create aninstance of the platonic object ID (165) in the user account (137),together with an identification of the version of the instance.Subsequently, during the rendering or presentation of the instance ofthe platonic object ID (165) in the user account (137), the serversystem (103) determines, based on the list of objects of differentversions identified in the platonic object (163), whether the platonicobject ID (165) has an updated/upgraded version. Thus, theupdate/upgrade can be performed just in time for the presentation of theinstance in the user account (137). The update or upgrade can beperformed in some instances automatically without user intervention. Theupdate or upgrade can be performed in some instances after a test and/orinspection of the updated/upgraded version of the platonic object (163)by the user of the user account (137).

In FIG. 4 , the license ID (176) is used to identify a set of licenseterms and conditions of the object (151) for which the provenance node(171) is specified. A rule engine of the server system (103) can beprogrammed to enforce the terms and conditions of the object (151).

In FIG. 4 , the price (177) specified in the provenance node (171) ofthe object (151) identifies the amount a purchaser is required to pay(e.g., using a virtual current, or other types of resources) in order toacquire an instance of the version of the platonic object (163)implemented via the object (151). The resource objects (153, 155, . . ., 157) have their respective provenance nodes to specify their creatorsand prices. The sum of the prices required by the creators of theresource objects (153, 155, . . . , 157) (and their resources) that arecreated by users other than the creator identified by the creator ID(174) of the provenance node (171) of the object (151) is the cost tothe creator in making and selling an instance of the object (151); andthe difference between the price and the sum is the net income derivedfrom the sale for the creator (or loss, if the price is too low, e.g.,in a form of incentive, charity, donation, distribution).

For example, after a sale of an instance of the object (151), the serversystem (103) charges the buyer of the instance according to the price(177) specified in the provenance node (171) of the object (151). Theobject (151) may be sold stand-alone, or as a resource object in anotherobject that uses the object (151) in its blueprint. Since the sale ofthe instance of the object (151) automatically effectuates the sale ofthe instances of the resource objects (153, 155, . . . , 157), theserver system (103) uses portions from the income generated from thesale of the instance of the object (151) according to the price (177) topurchase the instances of the resource objects (153, 155, . . . , 157)from the respective creators of the resource objects (153, 155, . . . ,157) according to the prices and create IDs specified in the provenancenodes of the resource objects (153, 155, . . . , 157). The process canbe performed recursively or iteratively to pay all creators involved inthe construction of the object (151). The creator of the object (151),as identified by the creator ID (174) of the provenance node (171) ofthe object (151), obtains the balance between the price (177) and thesum of the amounts used to purchase the instances of the resourceobjects (e.g., 153, 155, . . . , 157) (and their resource objects (e.g.,161)).

Since the server system (103) automatically performs the instanceacquisition according to the tree of provenance nodes (171) involved inthe object (151), it is not necessary for the creator of the object(151) to pre-purchase the instances of the resource objects (e.g., 153,155, . . . , 157) to create an inventory for “manufacturing” of theinstances of the object (151). Thus, the inventory management of thevirtual objects are greatly simplified. At the time of the sale of aninstance of the object (151), the server system (103) automaticallyacquires the required instances, via data replication and/or reference,and provides corresponding credits to the respective creators of theresource components in the blueprint hierarchy of the object (151), inaccordance with the creator IDs and prices specified in the provenancenodes of the respective resource objects (and their resource objects andso on).

The modifiability flag (178) of the provenance node (171) of the object(151) indicates whether a user, different from the creator of the object(151) (as identified by the creator ID (165)), is allowed to makemodifications to an instance of the object (151) acquired by the user.

When the modifiability flag (178) is in a state that prohibitsmodifications, the user may use the instance of the object (151) as awhole, without changing the blueprint of the object (151). The user mayconnect the object (151) to other objects to make a new object. The usermay transform the object (151) as a whole, attach other objects to itvia joints, or wire in additional parameter nodes to the content of theobject (151). However, the user is not allowed to add contents to theobject (151), remove contents from the object (151), and/or edit thecontents of the object (151). In some instances, the user may setuser-customizable parameters of the object (151).

When the modifiability flag (178) is in a state that allowsmodifications, the user is allowed to change the blueprint of the object(151) to create a new object, with or without the use of additionalresource objects. For example, the user may add contents to the object(151), remove contents from the object (151), and/or edit the contentsof the object (151), including non-customizable parameters. In theblueprint of the new object created by the user, the object (151) isidentified as a resource.

The extractability flag (178) of the provenance node (171) of the object(151) indicates whether the resource objects (e.g., 153, 155, . . . ,157) of the object (151) can be taken out of the context of the object(151) and used elsewhere.

For example, if the virtual wheels of a virtual car are extractable, theuser of the virtual car may extract the virtual wheels and useelsewhere. However, if the virtual wheels of the virtual car are notextractable, the user may remove the virtual wheel from the virtual car,discard the virtual wheel, and/or add other virtual wheels to thevirtual car to make a new virtual car. The user may remove the virtualwheel and repurpose the virtual wheel as a decorative item on thevirtual car, or not use the virtual wheel removed from the virtual car.However, the user is prevented from adding to an inventory the virtualwheels, extracted from the virtual car, and later using the virtualwheel in a context outside the virtual car.

FIG. 5 illustrates a data structure to implement access control for avirtual object having multiple versions according to one embodiment. Forexample, the data structure of FIG. 5 can be implemented using theobject (151) of FIG. 2 , the platonic object (163) of FIG. 3 , and theprovenance node (171) of FIG. 4 .

In FIG. 5 , a plurality of versions of a virtual item can be created asa plurality of objects (187, 188, . . . , 151). Each of the objects(187, 188, . . . , 151) has a blueprint of its construction from one ormore resource objects (e.g., 153, 155, . . . , 157, as illustrated inFIG. 2 for the object (151)).

A platonic object (163) has a version history of the virtual item in theform of a list of object IDs (167, 168, . . . , 169). The platonicobject (163) represents the virtual item in general. Each of the objectIDs (167, 168, . . ., 169) identifies a corresponding one of the objects(187, 188, . . . , 151) of respective versions. Through the referencemade via the object IDs (167, 168, . . . , 169), the server system (103)can readily render any version of the platonic object (163) using theblueprint of the respective object (e.g., 187, 188, . . . , or 151).

Each of the objects (187, 188, . . . , 151) of respective versions has aprovenance node (e.g., 181, 182, . . . , 171) that specifies the accesscontrol parameters of the object (e.g., 181, 182, . . . , 171). Theprovenance nodes (181, 182, . . . , 171) of the objects (187, 188, . . ., 151) of respective versions have the same platonic object ID (165)that identifies the platonic object (163). Thus, from each object (e.g.,181, 182, . . . , 171) (and its instances), the server system (103) canefficiently determine the complete revision history of the virtual itemfrom the reference made using the platonic object ID (165).

In some instances, some of the objects (187, 188, . . . , 151) ofrespective versions may optionally share a same provenance node (e.g.,171) (e.g. when such objects have the same access control parameters).

In some instances, the original objects (e.g., 181, 182, . . . , 171)having the blueprints are owned by the creator(s) of the objects. Othersmay obtain an instance of the platonic object (163) with an indicationof the obtained version of the platonic object (163), such that theupdates/upgrades can be performed just in time for the use of aninstance of the platonic object (163).

In some instances, the platonic object (163) is stored as a centralizedrecord for the version history of the objects (e.g., 181, 182, . . . ,171) of different versions. The platonic object IDs (e.g., 165) providedin the provenance nodes (e.g., 171) of the objects (e.g., 181, 182, . .. , 171) allow the server system (103) to efficiently access the versionhistory and perform the update/upgrade of the instances of the objects(181, 182, . . . , 171) in an automated way.

FIG. 6 shows a method to implement access control for virtual objects ina virtual reality world according to one embodiment. For example, themethod of FIG. 6 can be implemented using the data structuresillustrated in FIGS. 2-5 in a computer system illustrated in FIG. 1 .

In FIG. 6 , a computer system is configured to: store (191) a platonicobject (163) identifying a list of objects (187, 188, . . . , 151) asdifferent versions of the platonic object (163); store (193) arespective blueprint of each respective object (e.g., 151) in the listof objects (187, 188, . . . , 151) to identify a set of resource objects(e.g., 153, 155, . . . , 157) that are used to construct the respectiveobject (151) in the virtual reality world; store (195) a provenance node(171) for the respective object (151) to identify the platonic object(153) (e.g., via the platonic object ID (165), a creator (e.g., via thecreator ID (174)) of the respective object (151), and a set of accesscontrol parameters (e.g., license ID (175), price (177), modifiabilityflag (178), extractability flag (179)) of the respective object (151);store (197) a respective provenance node having access controlparameters for each of the resource objects (e.g., 153, 155, . . . ,157); and control (199) access to instances of the platonic object (163)according to access control parameters stored in the provenance node(171) for the respective object (151) and the respective provenancenodes of the resource objects (153, 155, . . . , 157) of the respectiveobject (151).

The computer system (e.g., as illustrated in FIG. 1 ) hosts athree-dimensional virtual reality world and includes a data storagedevice (105) and a server computer/system (103). The data storage device(105) stores a three-dimensional model (131) of the virtual realityworld and avatar models (135) representing residences of the virtualreality world. The data storage device (105) also stores the platonicobject (163), the list of objects (187, 188, . . . , 151) as differentversions of the platonic object (163), including their blueprints andprovenance nodes (e.g., 171). The server computer/system (103) rendersthe three-dimensional model (131) of the virtual reality world accordingto view points of avatars (e.g., 141) generated according to the avatarmodels (135), including instances of the platonic object (151) that areadded to the virtual reality world (e.g., by users of the users accounts(e.g., 137)). The server computer/system (103) controls access to theinstances of the platonic object (163) according to access controlparameters stored in the tree of provenance nodes connected via thereferences to the list of objects (187, 188, . . . , 151) in theplatonic object (163), the references to the resource objects (e.g.,153, 155, . . . , 157) in the blueprint of the respective objects (e.g.,151), and the provenance nodes (e.g., 171) of the objects involved. Insome implementations, a provenance node (171) has explicit references toprovenance nodes of its component objects (153, 155, . . . , 157) and/orexplicit references to the component objects (153, 155, . . . , 157)such that the references from the provenance node (171) to provenancenodes of its component objects (153, 155, . . . , 157) and theprovenance nodes of the component objects of the component objects (153,155, . . . , 157) and so on form a provenance node tree that allows forstraightforward application of permissions and version upgrades tosub-trees.

The access to the instances of the platonic object (163) may include theusage of an instance of the respective object (151) in the creation of avirtual object in the virtual reality world, the acquisition of aninstance of the respective object (151) by users different from thecreator of the respective object (151), and/or the acquisition ofinstances of resource objects (153, 155, . . . , 157) of the respectiveobject (151) during the acquisition of an instance of the respectiveobject (151).

In general, the respective object (151) has a shape and a size visiblein the virtual reality world. A blueprint of the respective object (151)identifies: the positions of its set of resource objects (153, 155, . .. , 157) relative to each other within the respective object (151), andthe connections of the resource objects (153, 155, . . . , 157) to eachother within the respective object (151).

Access control parameters identified in a provenance node (171) for therespective object (151) includes at least one parameter identifying apermission to modify the blueprint of the respective object (151), suchas a permission indicating whether the respective object (151) ismodifiable by a user other than the creator in creating a new object, ora permission indicating whether the resource objects (153, 155, . . . ,157) of the respective object (151) are extractable for use in a contextoutside of the respective object (151) (e.g., whether resource objects(153, 155, . . . , 157) of an instance of the respective object (151)can be used in two or more instances of separate objects).

In one implementation, each instance of an object (e.g., 151) as aparticular version of the platonic object (163) is created as aninstance of the platonic object (163) having an indication of theparticular version. In response to a request to render the instance ofthe object (e.g., 151) as the particular version of the platonic object(163), the server computer/system (103) dynamically determines just intime, the availability of another object that serves in the platonicobject (163) as the update or upgrade of the object (e.g., 151). If thesuccessor version is available, the server computer/system (103)processes the migration from the instance of the current version of theplatonic object (163) to an instance of the next version of the platonicobject (163).

For example, the server computer/system (103) may automatically initiateand complete the migration based on compatibility between the currentversion of the platonic object (163) and the next version of theplatonic object (163), in view of a preference of a user of the instanceof the current version of the platonic object (163). For example, theuser of the user account (137) may provide a preference (147) thatallows the automatic update/upgrade based on compatibility and/or apredetermined cost criterion. In some instances, the servercomputer/system (103) prompts the user to test an instance of the nextversion of the platonic object (163) and accept the instance of the nextversion as a replacement of the current version.

When an instance of the platonic object (163) (e.g., the object (151) asa particular version of the platonic object (163)) is used in theconstruction blueprint of a further virtual object, the migrationprocessing includes the creation of an updated or upgraded version ofthe further virtual object by replacing the instance of the currentversion with an instance of the next version. When the servercomputer/system (103) presents the updated or upgraded version of thefurther virtual object to the creator of the further virtual object forinspection, optional adjustments, and/or approval. Thus, theupdate/upgrade can propagates to other virtual objects that useinstances of the platonic object (163).

Access control parameters of a provenance node (171) may identify alicense (176) for the respective object (151), and/or a price (177) ofthe respective object (151). Since the tree of provenance nodes inobjects (153, 155, . . . , 157, 161, . . . ) involved, directly orindirectly, in the blueprint of the respective object (151) identifiesthe prices and creators of the objects (153, 155, . . . , 157, 161, . .. ) involved, the server computer/system (103) can automaticallydistribute the revenue generated from an instance of the respectiveobject (151) to the respective creators according to the respectiveprices identified in the tree, to acquire the instances of objects (153,155, . . . , 157, 161, . . . ) involved in the blueprint of therespective object (151).

Each of the client devices (107, . . . , 109) and the server system(103) can be implemented in the form of one or more data processingsystems illustrated in FIG. 7 , with more or fewer components.

The present disclosure includes the methods discussed above, computingapparatuses configured to perform methods, and computer storage mediastoring instructions which when executed on the computing apparatusescauses the computing apparatuses to perform the methods.

FIG. 7 shows a data processing system on which the methods of thepresent disclosure can be implemented. While FIG. 7 illustrates variouscomponents of a computer system, it is not intended to represent anyparticular architecture or manner of interconnecting the components.Other systems that have fewer or more components than those shown inFIG. 7 can also be used.

In FIG. 7 , the data processing system (200) includes an inter-connect(201) (e.g., bus and system core logic), which interconnects amicroprocessor(s) (203) and memory (211). The microprocessor (203) iscoupled to cache memory (209) in the example of FIG. 7 .

In FIG. 7 , the inter-connect (201) interconnects the microprocessor(s)(203) and the memory (211) together and also interconnects them toinput/output (I/O) device(s) (205) via I/O controller(s) (207). I/Odevices (205) may include a display device and/or peripheral devices,such as mice, keyboards, modems, network interfaces, printers, scanners,video cameras and other devices known in the art. When the dataprocessing system is a server system, some of the I/O devices (205),such as printers, scanners, mice, and/or keyboards, are optional.

The inter-connect (201) includes one or more buses connected to oneanother through various bridges, controllers and/or adapters. Forexample, the I/O controllers (207) include a USB (Universal Serial Bus)adapter for controlling USB peripherals, and/or an IEEE-1394 bus adapterfor controlling IEEE-1394 peripherals.

The memory (211) includes one or more of: ROM (Read Only Memory),volatile RAM (Random Access Memory), and non-volatile memory, such ashard drive, flash memory, etc.

Volatile RAM is typically implemented as dynamic RAM (DRAM) whichrequires power continually in order to refresh or maintain the data inthe memory. Non-volatile memory is typically a magnetic hard drive, amagnetic optical drive, an optical drive (e.g., a DVD RAM), or othertype of memory system which maintains data even after power is removedfrom the system. The non-volatile memory may also be a random accessmemory.

The non-volatile memory can be a local device coupled directly to therest of the components in the data processing system. A non-volatilememory that is remote from the system, such as a network storage devicecoupled to the data processing system through a network interface suchas a modem or Ethernet interface, can also be used.

In this description, some functions and operations are described asbeing performed by or caused by software code to simplify description.However, such expressions are also used to specify that the functionsresult from execution of the code/instructions by a processor, such as amicroprocessor.

Alternatively, or in combination, the functions and operations asdescribed here can be implemented using special purpose circuitry, withor without software instructions, such as using Application-SpecificIntegrated Circuit (ASIC) or Field-Programmable Gate Array (FPGA).Embodiments can be implemented using hardwired circuitry withoutsoftware instructions, or in combination with software instructions.Thus, the techniques are limited neither to any specific combination ofhardware circuitry and software, nor to any particular source for theinstructions executed by the data processing system.

While one embodiment can be implemented in fully functioning computersand computer systems, various embodiments are capable of beingdistributed as a computing product in a variety of forms and are capableof being applied regardless of the particular type of machine orcomputer-readable media used to actually effect the distribution.

At least some aspects disclosed can be embodied, at least in part, insoftware. That is, the techniques may be carried out in a computersystem or other data processing system in response to its processor,such as a microprocessor, executing sequences of instructions containedin a memory, such as ROM, volatile RAM, non-volatile memory, cache or aremote storage device.

Routines executed to implement the embodiments may be implemented aspart of an operating system or a specific application, component,program, object, module or sequence of instructions referred to as“computer programs.” The computer programs typically include one or moreinstructions set at various times in various memory and storage devicesin a computer, and that, when read and executed by one or moreprocessors in a computer, cause the computer to perform operationsnecessary to execute elements involving the various aspects.

A machine readable medium can be used to store software and data whichwhen executed by a data processing system causes the system to performvarious methods. The executable software and data may be stored invarious places including for example ROM, volatile RAM, non-volatilememory and/or cache. Portions of this software and/or data may be storedin any one of these storage devices. Further, the data and instructionscan be obtained from centralized servers or peer to peer networks.Different portions of the data and instructions can be obtained fromdifferent centralized servers and/or peer to peer networks at differenttimes and in different communication sessions or in a same communicationsession. The data and instructions can be obtained in entirety prior tothe execution of the applications. Alternatively, portions of the dataand instructions can be obtained dynamically, just in time, when neededfor execution. Thus, it is not required that the data and instructionsbe on a machine readable medium in entirety at a particular instance oftime.

Examples of computer-readable media include but are not limited torecordable and non-recordable type media such as volatile andnon-volatile memory devices, read only memory (ROM), random accessmemory (RAM), flash memory devices, floppy and other removable disks,magnetic disk storage media, optical storage media (e.g., Compact DiskRead-Only Memory (CD ROM), Digital Versatile Disks (DVDs), etc.), amongothers. The computer-readable media may store the instructions.

The instructions may also be embodied in digital and analogcommunication links for electrical, optical, acoustical or other formsof propagated signals, such as carrier waves, infrared signals, digitalsignals, etc. However, propagated signals, such as carrier waves,infrared signals, digital signals, etc. are not tangible machinereadable medium and are not configured to store instructions.

In general, a machine readable medium includes any mechanism thatprovides (i.e., stores and/or transmits) information in a formaccessible by a machine (e.g., a computer, network device, personaldigital assistant, manufacturing tool, any device with a set of one ormore processors, etc.).

In various embodiments, hardwired circuitry may be used in combinationwith software instructions to implement the techniques. Thus, thetechniques are neither limited to any specific combination of hardwarecircuitry and software nor to any particular source for the instructionsexecuted by the data processing system.

OTHER ASPECTS

The description and drawings are illustrative and are not to beconstrued as limiting. The present disclosure is illustrative ofinventive features to enable a person skilled in the art to make and usethe techniques. Various features, as described herein, should be used incompliance with all current and future rules, laws and regulationsrelated to privacy, security, permission, consent, authorization, andothers. Numerous specific details are described to provide a thoroughunderstanding. However, in certain instances, well known or conventionaldetails are not described in order to avoid obscuring the description.References to one or an embodiment in the present disclosure are notnecessarily references to the same embodiment; and, such references meanat least one.

The use of headings herein is merely provided for ease of reference, andshall not be interpreted in any way to limit this disclosure or thefollowing claims.

Reference to “one embodiment” or “an embodiment” means that a particularfeature, structure, or characteristic described in connection with theembodiment is included in at least one embodiment of the disclosure. Theappearances of the phrase “in one embodiment” in various places in thespecification are not necessarily all referring to the same embodiment,and are not necessarily all referring to separate or alternativeembodiments mutually exclusive of other embodiments. Moreover, variousfeatures are described which may be exhibited by one embodiment and notby others. Similarly, various requirements are described which may berequirements for one embodiment but not other embodiments. Unlessexcluded by explicit description and/or apparent incompatibility, anycombination of various features described in this description is alsoincluded here. For example, the features described above in connectionwith “in one embodiment” or “in some embodiments” can be all optionallyincluded in one implementation, except where the dependency of certainfeatures on other features, as apparent from the description, may limitthe options of excluding selected features from the implementation, andincompatibility of certain features with other features, as apparentfrom the description, may limit the options of including selectedfeatures together in the implementation.

In the foregoing specification, the disclosure has been described withreference to specific exemplary embodiments thereof. It will be evidentthat various modifications may be made thereto without departing fromthe broader spirit and scope as set forth in the following claims. Thespecification and drawings are, accordingly, to be regarded in anillustrative sense rather than a restrictive sense.

What is claimed is:
 1. A method, comprising: storing, in a data storage of a server computer hosting a virtual reality world, a platonic object identifying a list of objects as different versions of the platonic object; storing, in the data storage, a set of resource objects, for each respective object in the list of objects, that are used to construct the respective object in the virtual reality world; storing, in the data storage, a node for the respective object in the list of objects, wherein the node of the respective object identifies: the platonic object; and a set of access control parameters of the respective object, wherein each of the set of resource objects has a respective node having access control parameters.
 2. The method of claim 1, wherein the respective object has a shape and a size in the virtual reality world.
 3. The method of claim 2, wherein the set of resource objects identify: positions of the set of resource objects relative to each other within the respective object.
 4. The method of claim 2, wherein the set of access control parameters identified in the node for the respective object includes at least one parameter identifying a permission to modify the respective object.
 5. The method of claim 4, wherein the permission indicates whether the respective object is modifiable by a user other than a creator in creating a new object.
 6. The method of claim 4, wherein the permission indicates whether the resource objects of the respective object are extractable for use in a context outside of the respective object.
 7. The method of claim 2, wherein each instance of a first object in the list of objects that are different versions of the platonic object is created as an instance of the platonic object having an indication of a version corresponding to the first object.
 8. The method of claim 7, wherein in response to a request to render the instance of the first object, the method further comprises: determining availability of a second object in the list of objects that are different versions of the platonic object, wherein the second object is a successor version of the first object; and processing migration from the instance of the first object to an instance of the second object.
 9. The method of claim 8, wherein the server computer automatically initiates and completes the migration based on a compatibility between the first object and the second object and a preference of a user of the instance of the first object.
 10. The method of claim 8, wherein the processing migration includes prompting a user of the instance of the first object to test an instance of the second object and accepting the instance of the second object as a replacement of the instance of the first object.
 11. The method of claim 8, wherein the instance of the first object is used in construction of a virtual object; and the processing migration includes creating an updated or upgraded version of the virtual object by replacing the instance of the first object with an instance of the second object.
 12. The method of claim 2, wherein the set of access control parameters identified in the node for the respective object identifies a license for the respective object.
 13. The method of claim 2, wherein the set of access control parameters identified in the node for the respective object identifies a price for the respective object.
 14. The method of claim 2, wherein the respective node of each of the set of resource objects identifies a first price and a first creator.
 15. The method of claim 14, wherein in response to a sale of an instance of the respective object, the method further comprises: acquiring, automatically by the server computer, an instance of each of the set of resource objects of the respective object according to the first price from the first creator.
 16. A non-transitory computer storage medium storing instructions configured to instruct a server computer to perform a method, the method comprising: storing, in a data storage of a server computer hosting a virtual reality world, a platonic object identifying a list of objects as different versions of the platonic object; storing, in the data storage, a set of resource objects, for each respective object in the list of objects, that are used to construct the respective object in the virtual reality world; storing, in the data storage, a node for the respective object in the list of objects, wherein the node of the respective object identifies: the platonic object; and a set of access control parameters of the respective object, wherein each of the set of resource objects has a respective node having access control parameters.
 17. A computing system, comprising: a data storage device storing: a three-dimensional model of a virtual reality world; a platonic object identifying a list of objects as different versions of the platonic object; a respective blueprint of each respective object in the list of objects, the respective blueprint identifying a set of resource objects that are used to construct the respective object in the virtual reality world; and a provenance node for the respective object in the list of objects, wherein the provenance node of the respective object identifies: the platonic object; and a set of access control parameters of the respective object, wherein each of the set of resource objects has a respective provenance node having access control parameters.
 18. The computing system of claim 17, wherein the access to the instances of the platonic object includes usage of an instance of the respective object in creation of a virtual object in the virtual reality world.
 19. The computing system of claim 17, wherein the access to the instances of the platonic object includes acquisition of the instances by users different from one or more creators of the list of objects that are different versions of the platonic object.
 20. The computing system of claim 17, wherein the access to the instances of the platonic object includes acquisition of instances of the set of resource objects of the respective object during acquisition of an instance of the respective object. 